1. Field of the Invention
The present invention generally relates to the fields of modeling, optimization, and control. More particularly, the present invention relates to providing an enterprise wide framework for constructing modeling, optimization, and control solutions. The present invention further relates to various techniques for performing improved modeling, optimization, and control, as well as improved scheduling and control.
2. Description of the Related Art
Numerous industries are in the midst of a technological revolution. Throughout today's businesses, information is being made available from diverse sources at a rapid rate. In addition, abundant amounts of historical data from these sources are accumulating but are not being fully leveraged. Customers expect immediate responses and demand the highest quality products and services. To remain competitive, businesses must be able to operate optimally while fulfilling the customers' needs.
The need to operate optimally requires that businesses be much more flexible, have immediate access to different forms of information throughout the enterprise, and be able to use this information to solve problems in real time. A business must be able to utilize the information effectively and react to the information as it becomes available rather than waiting for it to appear in periodic reports. The problem is that the information comes from different areas of the business, has different meaning to different levels of the business operation, and is utilized in different ways. The business must be able to gather information, analyze the information, utilize the information, and execute decisions all in an optimal manner with respect to the entire business in order for it to operate most profitably.
Tools have been developed to improve separate aspects of business operations. Examples include tools for supply chain management and advanced process control. However, these tools applied in isolation do not solve the enterprise-wide problems. An enterprise-wide solution is one that views the business as a whole. Although businesses have tried to integrate different individual solutions to achieve an enterprise-wide solution, these attempts have failed.
Integration of separate solutions into a single business solution is often misrepresented. The benefit of integration comes not from loose bridging between disjoint applications but rather from designing, from the beginning, tight integration of different applications. For example, one decision process cannot produce an optimal decision without knowing both the state of the process that it affects and the ramifications of that decision on the dependent processes.
Any successful solution to the enterprise-wide problem should have an integrated architecture that combines many diverse technologies into a unified framework. An enterprise-wide solution should have extensive information-handling capabilities, a complete set of automatic decision-making tools, and a flexible architecture that addresses the broad scope of problems faced throughout the enterprise.
FIG. 1 illustrates the concept of automated decision making according to the prior art. In automated decision making, it is presumed that a process or system exists upon which decisions are to be made. Part of the automated decision making process is to collect data, e.g., historical data of that process, and use this information to build knowledge or information about how the process behaves. This learning or knowledge may be continually added to or refined as the process is controlled. The information or knowledge that is gathered over time can then be used to perform intelligent decision making. For example, the knowledge about how the process behaves can be combined with goals and objectives of how the process is desired to behave in order to generate actions that can be used to manipulate the behavior of the process or system. Thus, a model of the system or process can be used in addition to a solver or optimizer that optimizes the process according to a desired problem formulation or objective function.
FIG. 2 is a flowchart diagram generally illustrating the prior art method of creating and using models and optimization procedures to model and/or control a process. As shown, in step 202 the method involves gathering historical data which describes the process. This historical data may comprise a combination of inputs and the resulting outputs when these inputs are applied to the respective process. This historical data may be gathered in many and various ways. Typically, large amounts of historical data are available for most processes or enterprises.
In step 204 the method may preprocess the historical data. The preprocessing may occur for several reasons. For example, preprocessing may be performed to manipulate or remove error conditions or missing data, or accommodate data points that are marked as bad or erroneous. Preprocessing may also be performed to filter out noise and unwanted data. Further, preprocessing of the data may be performed because in some cases the actual variables in the data are themselves awkward in modeling. For example, where the variables are temperature 1 and temperature 2, the physical model may be much more related to the ratio between the temperatures. Thus, rather than apply temperature 1 and temperature 2 to the model, the data may be processed to create a synthetic variable which is the ratio of the two temperature values, and the model may be used against the ratio.
In step 206 the model may be created and/or trained. This step may involve several steps. First, a representation of the model may be chosen, e.g., choosing a linear model or nonlinear model. If the model is a nonlinear model, the model may be a neural net structure. Further, the neural net structure may be a fully connected neural net or a partly connected neural net. After the model has been selected, a training algorithm may be applied to the model using the historical data, e.g., to train the neural net. Finally, the method may verify the success of this training to determine whether the model actually corresponds to the process being modeled.
In step 208 the model is typically analyzed. This may involve applying various tools to the model to discover its behavior.
Finally, in step 210, the model may be deployed in the “real world” to model, predict, optimize, or control the respective process. The model may be deployed in any of various manners. For example, the model may be deployed simply to perform predictions, which involves specifying various inputs and using the model to predict the outputs. Alternatively, the model may be employed with a problem formulation, e.g., an objective function, and a solver or optimizer.
FIG. 3 illustrates the traditional prior art approach to scheduling/optimization problems. FIG. 3 is a graph which illustrates various types of decisions and the prior art methods typically used in making these decisions. The graph has two axes as shown. The X axis represents the process and decision type. The X axis represents the process type ranging from continuous processes at the origin, to batch processes, and then to discrete processes. In a continuous process, material is continuously flowing through a system, and the automation solution may be continuously gathering measurements and continuously making decisions. A batch process presumes that the process occurs in batches. The Y axis represents the scope and resolution of the decisions being made. At the origin, the scope and resolution of the decisions are local involving very simple decisions. As Y increases decisions become more complex, until at the highest point of the Y axis the system involves planning the strategy of a whole enterprise.
As shown in FIG. 3, prior art solutions applied in this matrix are typically very distinct in nature. For example, control solutions in a continuous world and a control solution in a batch world have very little common software or common representation. Rather, these are typically different products. This limits the ability to create more interesting and intelligent solutions to various problems.
As shown, the prior art approach has typically used an “islands of technology” approach comprising separate applications, e.g., a separate scheduler application, a separate recipe execution application, and a separate controller application. A solution provider may then attempt to combine these separate applications using a form of “glue logic” that enables some forms of primitive communication. One of the drawbacks with this traditional approach is that the applications generally can only exchange basic, static information. In addition, these different high-level applications typically have differences in modeling, framework, communication, visualization, and execution, and lack adequate intercommunication to provide a true enterprise-wide solution.
Thus, the traditional prior art approach to decision making across the enterprise may be referred to as “system integration”. The prior art method presumes different pieces of software that may perform different functions, such as continuous control, batch control, optimization, scheduling, etc., and these different pieces are “glued together” to attempt to provide an enterprise solution. In addition, as mentioned above, each of these different applications cannot take advantage of all of the enterprise data which would be desirable to optimize the entire enterprise.
Therefore, an improved system and method are desired for providing a modeling, optimization, and control system. An improved system and method are also desired for providing various improved modeling, optimization, and control techniques.